1. Field of the Invention
The present invention is directed to electronic systems that employ token-passing to control access to shared resources and, more particularly, to fault protection schemes for such systems.
2. Discussion of Related Art
In electronic systems, it is common for two or more pieces of equipment (e.g., “clients”) to access to a single shared resource. For example, in multi-port memories, two or more ports access a single random-access memory (RAM) array to write data thereto or to read data therefrom. Because, in many situations, a shared resource can be used by only one client at a time, it is generally undesirable for two clients to be permitted to access the shared resource simultaneously. Various schemes therefore have been developed to control access to shared resources (e.g., memory arrays) by groups of clients (e.g., memory ports) so that only one client can access the resource at a time.
One of these schemes is called a “token ring.” A token ring is group of clients that are interconnected to pass a virtual token among them in a ring-like fashion, with each client being permitted to access a resource shared by all of the clients in the group only when it is in possession of the token. A token may be, for example, a single bit or several bits that can be passed from one client to another in the token ring.
An example of a prior art token-passing scheme, as applied to a dual-port memory 101 (i.e., a memory having two independently accessible ports), is shown in FIG. 1. As shown, shared resource 100 (a RAM array) is shared by a first client 104a (Port A) and a second client 104b (Port B). The clients 104a and 104b are able to access the shared resource 100 via a single, shared bus 102. The bus 102 includes data lines and control lines to exchange data and control information, respectively, between the clients 104a and 104b and the shared resource 100.
The clients 104a and 104b also are connected, respectively, to system interface busses 108a and 108b which, in the example shown, provide paths for data to be written from an external system component (not shown) to the dual-port memory 101. Each of the clients 104 may include write buffers (not shown) that store data written from the external system component prior to the data being written by the client to the shared resource 100. Similarly, each of the clients 104 may include read buffers (not shown) that store data read from shared resource 100 and make the stored data available to the external system component. These read and write buffers may be implemented using first-in-first-out buffers (FIFOs) so that data may be transferred to and from the buffers asynchronously. Additionally, selectively enablable drivers (not shown) may be included in each of the clients 104 to provide an interface to the bus 102. By selectively enabling only a particular client's drivers, that client may be given exclusive control of the bus 102.
Once the external system component (not shown) has written data to a write buffer in the client 104a or the client 104b (via the bus 108a or the bus 108b, respectively), the data remains in that client's write buffer until the client is able to gain control of the bus 102 to access the shared resource 100 and write the data thereto. Similarly, when the external system requests that the client 104a or the client 104b read data from the shared resource 100, the external system waits until the client is able to gain control of the bus 102 to access the shared resource 100 and read the data therefrom.
If the two clients 104 were permitted to control the bus 102 simultaneously, the signals that would be placed on the bus 102 would run the risk of being in contention. That is, signals having opposite logic states may contend for the same bus lines. This is an undesirable result which can cause data transmission errors and/or damage to circuitry connected to the bus 102.
In the embodiment shown in FIG. 1, to avoid having the clients 104a and 104b place contending signals on the bus 102, the clients 104a and 104b are interconnected as a token ring to ensure that only one of the clients 104a and 104b has control of the bus 102 to access the shared resource 100 at any given time. Specifically, a token_in terminal 110a of the client 104a is electrically connected (via a wire 106b) to a token_out terminal 112b of the client 104b, and a token_in terminal 110b of the client 104b is electrically connected (via a wire 106a) to a token_out terminal 112a of the client 104a. Using these token ring connections, a virtual token is passed between the clients 104a and 104b. Only one of the clients 104a and 104b is in possession of the token at a given time, and that client is given exclusive control of the bus 102.
This granting of exclusive control of the bus 102 to one of the clients 104a and 104b may be accomplished, for example, by enabling the drivers in the client having possession of the token and disabling the drivers in the other client. Thus, during the time period that each client is in possession of the token, that client may access the shared resource 100 over the bus 102.
When the client 104 in possession of the token has completed its accessing of the shared resource 100, or if the client 104 receives the token at a time when it does not require access to the shared resource 100, it gives up possession of the token by placing an appropriate signal on its token_out terminal 112. After giving up possession of the token, the client 104 monitors its token_in terminal 110 until it receives the token from the token_out terminal 112 of the other client 104. In this manner, the token is passed continuously from one client 104 to the other.
In the system shown in FIG. 1, each of clients 104a and 104b may be programmed with information that enables it, based upon the current logic states of the signals on its token_in and token_out terminals 110 and 112, to identify whether it is in possession of the token at any given time. For example, the client 104a may be programed such that it is in possession of the token only when the signals on its token_in and token-out terminals 112a and 110b are in the same state, and client 104b may be programmed such that it is in possession of the token only when the signals on its token_in and token-out terminals 110b and 112b are in opposite logic states.
Thus, in this example, because the signals on the lines 106a and 106b are either in the same logic state or opposite logic states at all times, only one client will possess the token at all times. The client 104 that is in possession of the token at any given time may transfer it to the other client simply by inverting the logic state (i.e., “toggling”) of the signal on its token_out line 112.
When the system shown in FIG. 1 initially receives power, the logic states of the signals on lines 106a and 106b may, for example, both be initialized to be in the logic low state. Because, in this example, the signals on lines 106a and 106b are initially in the same logic state, client 104a has initial possession of the token and may access shared resource 100.
When client 104a is ready to pass the token to client 104b for the first time after power-up, i.e., when client 104a has finished accessing the shared resource 100 or determines that it does not currently require access to the shared resource 100, the client 104a toggles the signal on its output terminal 112a from the logic low state to a logic high state. Because this toggling causes the signals on lines 106a and 106b to be in different logic states, client 104b now is in possession of the token and may access the shared resource 100.
When client 104b is ready to pass the token back to client 104a, it toggles its output terminal 112b from the logic low state to the logic high state, thereby causing the signals on lines 106 to be in the same logic state, so that client 104a again gains possession of the token.
Subsequently, when client 104a is ready to pass the token once again, it will toggle its output terminal 112a from the logic high state to the logic low state, causing the signals on lines 106a and 106b to be in different logic states and thereby passing the token back to client 104b. Finally, when client 104b is again ready to pass the token, it will toggle its output terminal 112b from the logic high state to the logic low state, causing the signals on lines 106a and 106b to be in the same logic state and thereby passing the token back to client 104a. At this point, the signals on lines 106a and 106b are both in the logic low state, as they were when the system initially received power. This process repeats itself indefinitely so that clients 104a and 104b repeatedly pass the token back and forth.
As shown in FIG. 1, shared resource 100 may include a RAM array. This RAM array may be implemented using a static random-access memory (SRAM) array or a dynamic random-access memory (DRAM) array. If a DRAM array is used, each of the rows of the array must be refreshed periodically, e.g., every “64” milliseconds (ms), to retain the data stored therein. For a DRAM array including, for example, “4096” rows, one row must be refreshed approximately every fifteen microseconds (μs) to ensure that each row in the array is refreshed every 64 ms (i.e., 64 ms/4096 rows≈15 μs/row).
If a DRAM array is used in the system shown in FIG. 1, clients 104a and 104b can share the responsibility for performing this row-refreshing function. To this end, each of clients 104a and 104b can include a counter (not shown) which keeps track of the elapsed time between consecutive row-refreshing operations. If, upon receiving the token (as described above), the counter in one of clients 104a and 104b indicates that more than a particular amount of time has elapsed (e.g., 15 μs) between consecutive row-refreshing operations, that client can perform the refreshing function and the counters in both of clients 104a and 104b can be reset. The shared resource 100 can include circuitry for keeping track of the order in which rows are refreshed so that clients 104a and 104b can simply perform refresh operations (when required) without needing to know which particular row of the shared resource 100 is being refreshed by each operation.
While the prior art system shown in FIG. 1 is reliable under most circumstances, Applicants have recognized that a circuit error or failure in one of the clients 104a and 104b can, under certain circumstances, adversely affect the functionality of the token-passing scheme, thereby leading to the inability of both of the clients 104a and 104b to access the shared resource 100. For example, Applicants have recognized that a circuit anomaly within the client 104a may cause it erroneously to perceive that it is the client 104b, or vice versa. This error can lead to the failure of the token-passing scheme since its occurrence will cause the clients 104a and 104b to perceive either: (1) that they are both in possession of the token, or (2) that they are both not in possession of the token.
For example, if the client 104a erroneously perceives that it is the client 104b, then when the signals on lines 106a and 106b are in the same logic state, both clients will believe that they are not in possession of the token, and when the signals on lines 106a and 106b are in different logic states, both clients will believe that they are in possession of the token. Similarly, if client 104b erroneously believes that it is client 104a, then when the signals on lines 106a and 106b are in the same logic state, both clients will believe that they are in possession of the token, and when the signals on lines 106a and 106b are in the different logic states, both clients will believe that they are not in possession of the token.
Any of these situations can cause problems with the token-passing scheme used in FIG. 1. That is, if both clients have possession of the token, then signals placed on the shared bus 102 by the clients 104 can be in contention with one another. And, if neither client has possession of the token, then each client will wait idly for a state change on its token_in terminal 110, and neither client will be able to access shared resource 100. This second condition can be particularly problematic if the resource being shared by clients 104a and 104b is a dynamic random-access memory (DRAM). That is, because clients 104a and 104b generally share the responsibility of refreshing the DRAM, if neither of them is in possession of the token, then neither of them will refresh the memory and the current contents of the DRAM can be lost.
FIG. 2 shows an example of a prior art system in which Applicant has recognized that a circuit anomaly might occur that can lead one of the clients 104 to perceive that is the other client. As shown, client 104a includes a programmable logic device (PLD) 202a and an application specific integrated circuit (ASIC) 204a, and client 104b includes a PLD 202b and an ASIC 204b. The ASICs 204a and 204b are configured identically to reduce their development cost as compared with developing two different ASICs. However, the PLDs 202a and 202b, which are less expensive to implement, contain different initialization or bootstrap information for the ASICs 204a and 204b, respectively, and are therefore configured differently. The bootstrap information is used by each ASIC 204 to identify, for example, whether it is included in the client 104a or the client 104b. 
As shown, the bootstrap information is provided from the PLDs 202a and 202b to the ASICs 204a and 204b, respectively, via lines 206a and 206b. The bootstrap information is transferred from the PLDs 202 to the ASICs 204 when the system initially receives power. The bootstrap information also is transferred to one of the ASICs 204 each time the PLD 202 associated therewith detects (e.g., via monitoring lines 208) an anomaly in the operation of the ASIC 204 and causes the ASIC 204 to be reset. Such an anomaly may include, for example, a failure of the ASIC 204 to refresh the DRAM array (i.e., shared resource 100) within a particular time period. When such an anomaly is detected by one of the PLDs 202, that PLD 202 provides an active signal on its reset line 210, which is connected between the PLD 202 and the ASIC 204, to reinitialize the ASIC 204. As a part of its reinitialization routine, the ASIC 204 requests the bootstrap information from the PLD 202.
As mentioned above, the bootstrap information transferred to one of ASICs 204 from the PLD 202 associated therewith initializes the ASIC 204 with information that identifies it as being included either in client 104a or client 104b. This bootstrap information identifies, for each client: (1) whether the client 104 is to possess the token when the signals on lines 106a and 106b are in the same logic state or in different logic states, and (2) whether, upon initialization, the client is initially to provide a signal on its token_out terminal 212 that is in a high logic state or a low logic state.
Applicants have recognized that PLDs 202 may occasionally fail such that the bootstrap information that each PLD 202 provides to the ASIC 204 with which it is associated may be inaccurate. Such inaccurate bootstrap information can, for example, cause the ASIC 204 receiving the information to believe that it is the other ASIC 204 in the system. This misidentification of the ASIC 204 can cause the problem discussed above wherein one of the clients can mistakenly perceive that it is the other. Additionally, although the PLDs 202 may be tested for anomalies at the time they are first installed in the system and may be replaced or reprogrammed at that time if they are found to be faulty, the PLDs 202 are also subject to failures after the system has been installed and operating for an extended period of time. Such latent failures of the PLDs 202 can cause serious problems in the system that will persist until service personnel can identify and fix the problem.
In the embodiment shown in FIG. 2, the PLDs 202 monitor the signals on the enable lines of the drivers (not shown) included in the clients 104 to detect occasions when the signals are active concurrently and both of the clients 104 are erroneously given simultaneous access to the shared resource 100. If such a condition is detected, then the PLD 202 associated with one or both of the clients 104 provides an active signal on its reset logic line 210, thereby reinitializing the ASIC 204 so that the ASIC 204 requests and receives the bootstrap information from the PLD 202. If this PLD 202 provides erroneous bootstrap information to the ASIC 204 that causes the ASIC 204 to believe that it is the other ASIC 204, however, this resetting of the ASIC 204 will not remedy the problem, since both ASICs 204 will still perceive that they are included in the same client. This misidentification of the ASICs 204 via the erroneous bootstrap information may eventually result in neither of the ASICs 204 being in possession of the token and in both of the clients 104 waiting idly for it. As described above, this situation can result in system errors and eventually data loss when, for example, a DRAM array is not refreshed by either of the clients 104.